========== psion/sibosdk #908, from dw2, 3070 chars, Jul 31 23:12 94 ---------- Questions about object-oriented dialogs in HWIF If you've added one or more object-oriented dialogs to an Hwif application, using the hOODialog function in the v2 C SDK, sooner or later you're going to run into two questions: 1. How can you access your main code *data* from inside an oo dialog? 2. How can you access your main code *code* from inside an oo dialog? Both questions arise because HWIF.LIB forces the oo dialog to be in a separate DYL, ie in a different code segment from the main "image". The answer to 1. is fairly easy: you can reference global statics via "reserved Epoc statics" such as DatApp1 through DatApp7, which can be referenced in any DYL. Or you can use the final parameter to hOODialog, the "rbuf" parameter, to pass an address through from image code to the dialog code. Question 2. is more interesting. Eg you may want to call some validation code from inside the dialog. One answer to this is to duplicate the code in the DYL, as well as in the main image. Another approach is to try to separate the validation code, so that it is *only* called from the dialog. Better, however, is almost certainly to rebuild your own version of HWIF.LIB, declaring one or more new classes in there. To do this, you have to use your copy of the source code for Hwif, which is a standard part of the SDK release. This (optionally) gets installed into \sibosdk\hwifsrc. See the file READ.ME in that directory, for how to build your own version of HWIF.LIB, and how to *verify* that you have built it correctly. Then you have to alter the source file HWIF.CAT to add in one or more new classes. After the existing lines CLASS hprinter lprinter { REPLACE lpr_read REPLACE lpr_sense_text PROPERTY { INT (*sense)(WDR_PRINT *); } } CLASS hhelpdlg helpdlg { REPLACE destroy } add in new lines such as CLASS mygate root { ADD validate } Then rebuild HWIF.LIB. The next time you try to link your program, the linker will complain that there is an unresolved reference to a function mygate_validate. This is the function you have to provide. (You can provide it in one of your normal source modules - there's no requirement to try to build this function into HWIF.LIB too.) The code for mygate_validate (or whatever) will just consist of one line, that calls your real validation code, in the main image. Be sure to put a #pragma METHOD_CALL in front of this declaration. The way you call mygate_validate from the DYL can be as follows: GLREF_D VOID *DatApp1; p_send2(DatApp1,O_VALIDATE); (and you can pass extra parameters, as required, provided your code in mygate_validate expects them; also you can test the return value). This assumes you have already created an instance of the MYGATE class and written its handle to the Epoc static DatApp1. You can do this inside your main code segment, during program start-up as follows: GLREF_D VOID *DatApp1; DatApp1=f_new(CAT_HWIF_HWIF,C_MYGATE); Instead of DatApp1, you can use DatApp2, ..., or DatApp7. Regards, DavidW ========== psion/sibosdk #909, from dw2, 1704 chars, Jul 31 23:34 94 Comment to 908. ---------- Even better again, however, is to take the above approach to its conclusion. Instead of declaring "gate" classes in the main code image, it's arguably much easier to declare the dialog classes there, and eliminate the need for any DYLs. (You may of course have other good reasons for putting the dialog code into DYLs - eg to keep down the working set, or to improve programming modularity.) To make this easier, there's now a new variant of HWIF.LIB. It's called HWIFO.LIB, with the final "O" reflecting the fact that it's easier to program object-oriented dialogs using this. See HWIF203.ZIP in the FLIST of psion/files for an interim release of HWIF that contains both versions of the library, as well as an HWIF.H and an HWIF.CAT. The difference between the two libraries is that * HWIFO.LIB has had the HWIF.CAT bit missed out of it * so if you link this in instead of HWIF.LIB, you have to ensure that your own application includes a .CAT file that starts off by duplicating the contents of HWIF.CAT. As an example of this, see the file HWIFOQUE.ZIP also now in the FLIST of psion/files. This has identical functionality to the HWIFOOD example in v2 of the C SDK, but it has a much simpler build. Just unzip all the files into a single directory (\sibosdk\hwifoqu, say). If required, copy over the files TS.RED and RS.BAT from \sibosdk\hwdemo. Type "make" to build the .IMG. One particular advantage of all this, compared to the "gate class" approach, for easier inter-connection of oo dialog code and main image code, is that you don't have to mess with the library code. For another example, see FILETAGS.ZIP, yet another new addition in the FLIST. Regards, DavidW ========== psion/sibosdk #910, from dw2, 1699 chars, Jul 31 23:45 94 ---------- Tagging files in file selectors The question of programming tagged files in file selectors keeps recurring. The stock answer has been that it requires object-oriented dialogs to do it. This is because the programmer has to get into the code between 1. the user pressing ENTER to terminate the dialog 2. system code actually destroying the dialog ie the programmer has to "subclass" the dl_key method of the dialog. See FILETAGS.ZIP now in the FLIST of psion/files for how to do this in practice. This contains source code plus a complete built program. The code may be of interest for the additional reason that there are four different oo dialogs in it altogether, each slightly different. (You'll need to have some familiarity with the oo dialogs part of the C SDK to make sense of all of the code, but you should also be able to figure out quite a lot of what's going on just from the source code.) Despite having oo dialogs in it, the program is an Hwif one. However, it is written using HWIFO.LIB rather than HWIF.LIB. See other messages in this topic for more about HWIFO.LIB. The code shows how to use the two methods of the FNSELWN class that have to do with lists of tagged files - the FNS_EXTRACT_TAGS method and the FNS_INSERT_TAGS method. As you can see, what gets returned from FNS_INSERT_TAGS is a VARRAY object * whose first member is a ZTS giving the path of the tagged files * and whose other members are the "short" names of the tagged files. Regards, DavidW PS Don't be worried by a "hEnsurePath is defined twice" warning on linking this app. There's copies of this function in both HWIF.LIB and HWIM.LIB. These copies are functionally identical.